CVE-2024-57699 is irrelevant here as Spring Framework optionnally compiles against this dependency. Only applications depend on json-path.

Hi @bclozel, while Spring is not vulnerable merging it is a small upgrade that would remote CVE from future security scans. Are you sure you don't want to merge it?

@ivonaest I will merge it. I am just stating that this dependency will not show up in security scans because it is not declared in any of our artifacts. Only "spring-test" compiles against it and you can check that it does not depend on it in the published POM: https://central.sonatype.com/artifact/org.springframework/spring-test

Upgrading dependencies is an important concern, but it's even more important to understand how dependency management works and whether a CVE is applicable. Here it is not.

@bclozel Thank you for taking the time to explain CVE in this project. From my understanding, it is a false positive reported by Trivy scanner.

Can you share the part where Trivy points to spring-test as the culprit?

Trivy might be looking at the Gradle module information (where this dependency might show up) but is maybe missing the fact that it's not on the compile classpath.

It showed up only here

I don't understand why Trivy thinks spring-test has guava and other dependencies as transitive dependencies. Neither the POM file nor the Gradle module file lists anything like this. The commons-beanutils mention is also very strange.

If you can reach out to the Trivy team and get some answers, please let us know.

Thanks for your contribution @ivonaest

While I'm not sure it makes a real difference to applications, we are upgrading to json-path 2.10 in our maintenance releases due next week.

Hi @bclozel , sorry for the late reply, I have been talking to my colleagues about this. The lockfiles were generates with multiple scopes and Trivy was looking at all of them. For example checkstyle and other scopes, that's why guava was there.
Lockfiles have been modified so that they only contain compileClasspath and runtimeClasspath.
This is the Trivy output I am getting now:

And I appreciate the merge, thank you

@ivonaest It's still not clear why json-smart is pointing to spring-test as a dependent. Is your application depending on json-smart directly? How is the version managed? It looks like the problem lies in the lockfile generation and not in Trivy after all.

Note that depending on how this version is managed, the json-smart upgrade in Spring Framework might not solve your problem. Especially if json-smart is used outside of the test scope: Framework does not use json-smart outside of the test classpath.

@bclozel , with command
./gradlew spring-test:dependencyInsight --dependency json-smart --configuration runtimeClasspath
I get this output

From my understanding and this output, it looks like json-path uses json-smart as default parser and that's why it's pulling it in transitively through framework-platform. And spring-test has framework-platform on it's runtimeClasspath so that's why Trivy was showing it as CVE related to spring'test.

@ivonaest Wait a minute, so you're running Trivy against the spring-framework project directly? You shouldn't be doing that. Running security scanners against your own application is the only thing that matters. Unless you have forked spring-framework and you are re-building it internally?

We are using it internally but I am just contributing to open-source projects by remediating CVEs at the moment.